CMU-CS-85-174 Adaptability and Portability of Symbolic Debuggers

The design and implementation of symbolic debuggers for complex software systems is not a well understood area. This is reflected in the inadequate functionality of existing debuggers, many of which are seldomly used. For example, 30% of all programmers asked in a questionnaire (which was distributed as part of this thesis work) do not use a debugger at all or only very in frequently [Bruegge, 1984]. Yet debugging tools are needed: Many software systems are produced by the cooperative effort of many designers and programmers, sometimes over several years, resulting in products that inevitably contain bugs. There are three problems in the implementation and the use of symbolic debuggers. First, many programmers do not use debuggers because they are not available. Symbolic debuggers are costly to develop from scratch and the know-how to move an existing debugger in a cost-effective way from one machine to another is not available. To make debuggers more available, it must be possible to move them easily from existing to new machines. That is, they should be portable. Second, even if a symbolic debugger is available it is often quite inflexible to the different requirements of the various users or application programs. The functionality is wired into the code and the user is not able to tailor the debugger to the needs of the specific application to be debugged. Moreover, many debuggers are designed and implemented to operate only in exactly one programming environment. This is different from editors such as F._ACS [Gosling, 1982] where users are able to tailor the command language to their needs. A debugger should provide actually even more flexibility than a text editor: A debugger should be able to adapt to a variety of users and applications and environments. The third problem is that many existing symbolic debuggers depend heavily on the functionality made available by other components of the environment. However, these components are usually not designed with debugging in mind. As a result of this mismatch many debuggers cannot offer the functionality needed by programmers to debug their programs. This dissertation investigates these three problems and suggests how to overcome them. My thesis is that debuggers can be built more cost effectively and made more useful in a programming environment if they are portable and adaptable. The scientific contribution of this dissertation is the provision of a paradigm for building and using a debugger that is portable and adaptable. I define a language called PATrtRULESthat can be used as the basic building block of such a debugger. I demonstrate how PATIIRULEScan be used to implement the functionality of single process as well as multiple process debuggers. The language can also be used to adapt the debugger to sophisticated debugging situations not provided as built-in commands. I derive several requirements for builders of compilers, operating systems and hardware architectures to make PATtlRUI.ESimplementable. A prototype OfPATttRUI.EShas been implemented in KRAUT [Bruegge 1983b], a remote symbolic debugger for Perq Pascal [PQS, 1984] running under the Accent operating system [Rashid, 1981] as part of the SPICEproject [Ball, 1982]. The goal of the prototype implementation was to demonstrate the validity of key aspects of the approach and to observe the behavior of users during actual debugging situations. Altogether the debugging behavior of a population of 51 users was monitored in over 4000 debugging sessions spanning a period of more than two years. Based on these user studies I outline an implementation strategy for a portabie debugger and provide a bootstrap procedure to move a portable debugger from one environment to another.